Mobile communication devices may facilitate application functionality, such as payment over a wireless communication network. For instance, a mobile communication device (e.g., cellular telephone, mobile telephone, a smart phone) may include software and/or hardware that supports or enables wireless communication (e.g., near field communication or “NFC”) by the device with one or more wirelessly enabled point of sale terminals (POS terminals).
Conventionally, a backend system (e.g., a trusted service manager or “TSM”) itself comprising hardware and/or software, may enable an application service provider (e.g., American Express) to distribute its application functionality, such as contactless payment software (and functionality, as described herein), over a proprietary telecommunications network (or “Telco”) to a microcontroller (e.g., a Universal Integrated Circuit Card (“UICC”) or microSD card) located within the mobile communication device. This integrated circuit may be more generally referred to as a “secure element” to denote, for example, that the circuit may store an encryption key and/or a set of encryption keys used to authenticate the mobile device to a Telco and/or an application service provider using the over the air (OTA) Telco services.
GlobalPlatform (GP) is the industry standard for securely communicating with Secure Elements during manufacturing (i.e., pre-issuance) and while the Secure Elements are in the mobile devices held by consumers (i.e., post-issuance). Additionally, GP provides security controls to protect the sensitive data and cryptographic keys held in the Secure Element.
GP offers a range of cryptographic key management methods to enable the issuer of the Secure Element, such as a Telco, and the associated Service Providers. These include both “push” and “pull” models. An example of the push model is where an application service provider may request that a particular Telco provide (or provision) a cryptographic key or keys (e.g., a symmetric key or keys) to a particular secure element in response, for example, to a request by the user of the mobile communication device for certain contactless payment software and/or functionality. In response, the Telco may follow GP to generate (e.g., randomly generate) and provide the key(s) to the secure element on the mobile communication device. The secure element may store the key(s). The Telco may also securely provide a copy of the key to the application service provider. Thus, the secure element and the application service provider may share the key(s); that is, each entity may share this key as a “shared secret.” The mobile communication device may, in response to receipt of the shared secret, authenticate to the application service provider to receive the contactless payment software and/or functionality.
One aspect of GP is to have robust cryptographic key management. Hence, as part of this “push” process, it is conventionally necessary that the application service provider establish (or “rotate” to) a different cryptographic key(s), so that the Telco (which provided the original cryptographic key(s) to both the application service provider as well as to the secure element on the mobile device) is no longer able to decrypt communications between the application service provider and the mobile device. However, rotated keys are encrypted and provided to the secure element, under the key(s) provided by the Telco. Although a secure element may obtain rotated keys (that is, keys unknown to the Telco), it is conventionally possible for the Telco to decrypt the data packet containing the rotated keys during transmission to the secure element, because that packet is encrypted with the key(s) provided during the initial authentication stage by the Telco.
As the application service provider rotates to a new key set, it is also conventionally necessary that the application service provider collect and assemble the data necessary to enable its contactless payment functionality. This functionality may comprise the data necessary to complete a contactless payment transaction (e.g., a customer account number, a customer account payment limit, and the like). This collection of data may be referred to herein as “perso-data,” which may be collected into a file, which may be referred to herein as a “perso-script.” The perso-script may be generated in response to a request for such functionality and encrypted under session keys based on the rotated key(s). Hence, the perso-script may itself be at risk of decryption by the Telco.
GP also provides for a “pull” model, whereby the Secure Element generates a set of cryptographic keys and securely returns them to the Service Provider. This approach typically involves the use of public key cryptography and resolves the vulnerability of the Telco being able to expose the cryptographic keys (shared between the Secure Element and the Service Provider) or the sensitive data protected by those keys. However, even in the “pull” model the Service Provider may well want to rotate the keys held in the Secure Element so as to streamline cryptographic key management on the Service Provider's back end systems, e.g., deriving the keys held on the Secure Element from one or more master keys using Secure Element specific information.
A common challenge that both the “pull” and “push” methods face is that it is typically necessary that the application service provider generate the perso-script (including the rotated key(s) in response to receipt of a real-time request for contactless payment functionality. This means that the application service provider may have to maintain significant data processing resources to accommodate millions or tens of millions of requests occurring in real-time for contactless payment functionality. This may impose a significant burden on the processing resources (e.g., hardware) required to generate and encrypt each perso-script, and may in fact require that an application service provider maintain a large number of such data processing resources (including hardware security modules or “HSMs”).